1. Field of the Invention
Embodiments of the present invention relate to techniques for allocating processor registers during computational operations. More specifically, embodiments of the present invention relate to a technique for programmatically rewinding a register inside a transaction.
2. Related Art
Virtually all processors include a register file that contains registers which are used to store data. In many systems, the register file is divided into a number of general-purpose registers, which the processor uses to hold computational data, and special-purpose registers, which the processor uses to hold values such as a stack pointer or a frame pointer.
In addition, some processors support “register windowing,” wherein a register file is logically divided into a number of “register windows” each of which includes a set of the registers. For example, the SPARC™ architecture (from SPARC International, Campbell, Calif., USA) includes a large register file that is logically divided into a set of “global” registers that are visible in all register windows and a number of sets of “overlapping” register windows. Each of these overlapping register windows includes a set of “local” registers, and also shares a set of “in” registers with one adjacent register window, and shares a set of “out” registers with another adjacent register window.
More specifically, FIG. 1 presents a block diagram illustrating a SPARC register window. As shown in FIG. 1, there are a number of special-purpose registers in the register window, including % R30 which holds the frame pointer and % R14 which holds the stack pointer. The remaining registers in the register window are general-purpose registers for storing procedure arguments, local values, and return addresses. As described above, the register window includes “in,” “local,” and “out” registers. For a complete description of SPARC register windows, see David Weaver and Tom Germond, The SPARC Architecture Manual, version 9, pp. 29-34 and 301-305, PTR Prentice Hall, Englewood Cliffs, N.J.
Unfortunately, certain instructions, functions, or procedures (collectively, “procedures”) require more registers than are available in a register window. When a procedure has used all the allocatable registers in a given window, the processor either: (1) stores some registers in memory to free up the registers for the procedure, or (2) changes the current register window and starts using another register window for the procedure. In either case, the overhead of storing individual registers or changing register windows can degrade processor performance.
Some processors also include a floating-point register file that contains a number of registers that are used to store floating-point data. For example, the SPARC architecture includes a floating-point register file. However, in many systems, the floating-point register file does not support register windowing. Hence, if a procedure uses all of the floating-point registers, the processor starts storing the data in some of the floating-point registers to memory to free up floating-point registers for the procedure. When the stored data is subsequently required, the processor must load the data from memory to the floating-point register. Note that store and load operations are significantly slower than a register access. Consequently, floating-point procedures which cause registers to be stored can suffer performance degradation.
Hence, what is needed is a processor without the above-described problems.